Closed Bug 963933 Opened 11 years ago Closed 5 years ago

Search for elements by XPath selectors

Categories

(DevTools :: Inspector, enhancement, P2)

Product:
DevTools
Component:
Inspector
Version:
26 Branch
Type:
enhancement

Tracking

(firefox75 fixed)

Status:
RESOLVED FIXED
Milestone:
Firefox 75
Tracking Flags:
Tracking Status
firefox75 --- fixed

People

(Reporter: bghome, Assigned: sebo)

References

(Blocks 4 open bugs)

Details

(Keywords: dev-doc-complete)

Attachments

(3 files)

Bug 963933 - Allowed searching for elements via XPath in Inspector. r=jdescottes
47 bytes, text/x-phabricator-request
Details | Review
Bug 963933 - Tests for searching for elements via XPath in Inspector. r=jdescottes
47 bytes, text/x-phabricator-request
Details | Review
Broken DOM structure.png
8.27 KB, image/png
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release) Build ID: 20131205075310 Steps to reproduce: As a developer I want to find elements by typing a CSS or XPath expression. It could came handy when debugging or when testing. I would like to see support in DevTools for it. Actual results: Currently I can achieve this using JavaScript eg. jQuery. Expected results: I expect to have an input text filed for the CSS / XPath expression and a results list for the matched elements.
Severity: normal → enhancement
Component: Untriaged → Developer Tools: Inspector
OS: Windows 7 → All
Hardware: x86_64 → All
It's already possible to search via CSS selectors in the Inspector, as that's what is accepted by the search field there. Renaming this bug to be about XPath only, since CSS selector search already exists.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Inspect elements by CSS and XPath selectors → Search for elements by XPath selectors
Sorry, I did not see that CSS selector search is already implemented. I just have checked it, and it actually works very well.
(In reply to Géza Búza from comment #2) > Sorry, I did not see that CSS selector search is already implemented. I just > have checked it, and it actually works very well. Do you think XPath is also needed, or does selector search seem sufficient? My guess is that the number of web developers that know XPath well is much smaller than those that know CSS selectors.
Chrome is in the process of removing XSLT [1]. I suspect that XSLT is the largest [2] feature of browsers that has ever been actually removed. Sure, XSLT != XPath, but they're from the same family, and I'm not sure we need to add XPath features now. [1]: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/zIg2KC7PyH0[101-125-false] [2]: In terms of lines of code
@Ryan, @Joe I understand your concerns and basically agree with you. But I am going to describe why it could be useful for me. As a web developer when I have to write automated tests I often need to check the existance of a content in the current page. Let's say I need to look for a SPAN element with content in it. Here I can use an XPath like this: //span[text()='some content'] The same check with CSS selectors would involve more coding, because first I search for all SPAN, then read the text content from code one by one and check if one of the is equals to "some content". To sum up, I think Xpath is not a must have feature, but sometimes it could come handy.
(In reply to Géza Búza from comment #5) > To sum up, I think Xpath is not a must have feature, but sometimes it could > come handy. Selenium, right? I guess we *could* have devtools try an XPath match if querySelector failed, which would be low UI impact. But I'm still concerned that this is a deprecated feature. If FF follows Chrome in removing XSLT, and XPath comes next then we'd need to remove this feature.
That's right, I use Selenium. As far as I know XPath does not depend on XSLT, but XML document and XML Schema, so you can safely remove XSLT. And it is not so old piece of technology, because if you take a look at http://www.w3.org/TR/xpath20/ you can see that the second version was approved in 2010. Maybe some kind of usage statistic could help to decide. Anyway, do what you think is the best! :)
fwiw, we have the $x() helper which returns an array of matching nodes in the Console.
Thanks @Rob. That's fair enough.
No feedback on this for a while, and we don't have in our current plan to add support for XPATH now.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Blocks: firebug-gaps
Patrick, I got several requests lately related to FirePath not working anymore. Most of them are related to bug 987877, but some of them[1][2] are related to this one. Joe's point that XPaths are a deprecated feature might become valid in the future, though the latest spec.[3] is newer than his post and the thread related to Google's intent to deprecate XSLT[4] contains comments indicating that there is no intent to deprecate XPath. Therefore, I reopen this issue. Sebastian [1] http://stackoverflow.com/q/41992056/432681 [2] https://groups.google.com/d/msg/firebug/Q6eyvGt6hyI/yFFO5ji-CAAJ [3] https://www.w3.org/TR/xpath-30/ [4] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/zIg2KC7PyH0%5B1-25%5D
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Thanks Sebastian. These are good points. It is also a Firebug and Chrome gap. Let's triage this as a P2 enhancement.
Priority: -- → P2
There is also the case of XPath being the only method to walk the DOM up and down. There are many circumstances especially when testing that there is no ID or easy CSS way to get to the object. So, you have to do an XPath search for Value= or Text=, walk up the DOM, then back down to get to the object you want. I find XPath to be critical, and FirePath is my number one used add-in.
We need both (Xpath and Css). And i agree : The best tool with firebug is "FirePath", easy to use and work the both type. We need the same thing in Dev ToolBar. "There is also the case of XPath being the only method to walk the DOM up and down." : (for me) Xpath is harder to understand and the selector provided is not always the most accurate. I use in this case a tool provided by the quasi defunct Autopager addon (https://addons.mozilla.org/en-US/firefox/addon/autopager/). Its built in function to create a XPath by click some links on the pages is very intuitive and useful. If it is possible it should be a great improvement to include something similar to the Dev Toolbar.
I write automated tests (Selenium, Protractor, TestComplete) using a mix of CSS and XPath and all of the points mentioned above regarding XPath support make good sense to me: 1. //*[text()='<contentText>'] and //*[@class='<className>'] covers almost all of the elements I normally need 2. I use "FirePath" for quickly verifying the Xpaths before adding them to tests. It has been a life saver on more occasions than one and I would really want it back. 3. "There is also the case of XPath being the only method to walk the DOM up and down" - without this ability, some of the scenarios I have had to automate would have become very complicated.
I've been doing automated software testing for over 20 years now and although CSS is very helpful it tends to be more helpful for developers. Although a lot of my testing has shifted to API testing which does not require the GUI or any CSS or XPATH, for testing the headfull layer XPATH can be critical as testers do not always have access to the information they need to determine what element(s) to use and being able to traverse the DOM and type in an XPATH and see all the elements that it hits can save a lot of time and provides for a very large ROI.
Another automation engineer here. One of the nice features of firepath/bug was that you could search for elements via Xpath to ensure that your locators were identifying a unique match on the page...automation runs into issues when locators are not unique.
also posting my request for xpath locator. I used it all the time with Firepath, and would like to see it implemented here in the developer tools.
Just a hint for everyone asking for this feature in regard of automated testing: Selenium (and I'm sure other tools, too) also supports CSS selectors to select elements, which should be sufficient in most cases. There are a few cases where you still need XPaths, though, like selecting elements by their text contents (e.g. //*[text()='Text content']). Sebastian
Thanks for your comments so far folks. We'll prioritize this enhancement request. Note that the $x() function in the console can locate elements based on an xpath argument. It's not as nice as being able to run the xpath inside the search field of the inspector, but it's better than nothing. Example: $x("//html/body")
@Aditya and everyone interested in this feature, please read comment 23 and comment 20 for workarounds. Also, another workaround is to copy the XPath of an element via the context menu. Furthermore, there are currently two add-ons allowing to search elements by XPath.[1][2] (The latter doesn't seem to work for me, though.) Having said that, if you want to express your advocacy for this feature, please vote for it using the Vote button at the top instead of commenting. Please *only* comment if you want to provide information to help with the implementation. See https://bugzilla.mozilla.org/page.cgi?id=etiquette.html point 4 under "Commenting". Otherwise it's just noise for the others following this bug. Sebastian [1] https://addons.mozilla.org/firefox/addon/xpath_finder/ [2] https://addons.mozilla.org/firefox/addon/try-xpath/
Product: Firefox → DevTools

Searching for elements by XPath via the Inspector's find tool was a great alternative, but now it is also gone.
https://superuser.com/questions/1407080/how-do-i-search-with-xpath-in-firefox-quantum-65/1407554

(In reply to Sebastian Zartner [:sebo] from comment #31)

(In reply to 98gmarquee from comment #30)

I only see a "follow" button.

The Vote button is in the Details section at the top, right besides the number of votes.

Sebastian

Thanks!

Assignee: nobody → sebastianzartner

Because I am also missing this feature for quite some time now, I had a look into it and came up with a patch.

Two notes to the revisions:

  • The XPath search generally works quite well, though there is a case where it fails:
    Try //p/text() on devtools/server/tests/browser/inspector-search-data.html; The first time you hit Enter selects the text node of the <p> element (OK), but the second time changes the structure in the Inspector (see the attached screenshot).
  • The test devtools/client/inspector/test/browser_inspector_search-09.js fails on finding the text nodes. Instead, the containing element is selected.

Julian, it would be great if you helped me finding what's wrong. Thank you in advance!

Sebastian

Flags: needinfo?(jdescottes)

I found out what's causing the bug regarding searching for text nodes. Empty text nodes are not displayed in the Inspector, so they need to be filtered out when searching.

So only the test for finding the text nodes still needs to be fixed. And I don't know how yet, so help is still appreciated.

Sebastian

(In reply to Sebastian Zartner [:sebo] from comment #36)

I found out what's causing the bug regarding searching for text nodes. Empty text nodes are not displayed in the Inspector, so they need to be filtered out when searching.

So only the test for finding the text nodes still needs to be fixed. And I don't know how yet, so help is still appreciated.

Sebastian

Hi Sebastian!

Sorry about the delay. The reason your test fails is that we don't create "node fronts" for small text nodes (< 50 characters). They are called "inline text child", and are merged with their container.

If you add text nodes in your test document with more than 50 characters, they will be represented by dedicated node fronts in the markup view, and they will be individually selected.

Flags: needinfo?(jdescottes)

Thanks a lot for the hint with the > 50 characters, Julian! That was it.
I've updated the patch and fixed the tests according to your feedback.

If there are no more issues left, it would be great if that patch could still make it into 75. But no pressure!

Sebastian

Flags: needinfo?(jdescottes)

Reviewed. Happy we can get that in 75 as well, I played a bit with the feature and I found it really handy.

Flags: needinfo?(jdescottes)

Julian, can you please do the push to auto-land for me? I don't have the rights yet.

Sebastian

Flags: needinfo?(jdescottes)

(In reply to Sebastian Zartner [:sebo] from comment #40)

Julian, can you please do the push to auto-land for me? I don't have the rights yet.

Sebastian

Ok but I'll file a follow up to add a test which covers xPaths with a single starting / then.

Flags: needinfo?(jdescottes)
Pushed by jdescottes@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ed3f61f1c32c Allowed searching for elements via XPath in Inspector. r=jdescottes https://hg.mozilla.org/integration/autoland/rev/d33b655d9fab Tests for searching for elements via XPath in Inspector. r=jdescottes

Thanks for getting back to me! I've fixed the tests now.

Sebastian

Flags: needinfo?(sebastianzartner)
Blocks: 1620049
Pushed by cbrindusan@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b3e868335a61 Allowed searching for elements via XPath in Inspector. r=jdescottes https://hg.mozilla.org/integration/autoland/rev/89218ad04c6d Tests for searching for elements via XPath in Inspector. r=jdescottes

https://hg.mozilla.org/mozilla-central/rev/b3e868335a61
https://hg.mozilla.org/mozilla-central/rev/89218ad04c6d

Status: REOPENED → RESOLVED
Closed: 9 years ago → 5 years ago
status-firefox75: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 75

I've described this in https://developer.mozilla.org/en-US/docs/Tools/Page_Inspector/How_to/Examine_and_edit_HTML#Searching and added a release note for it at https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/75.

Will, can you please have a look and tell me if it's ok?

Sebastian

Flags: needinfo?(wbamberg)

Thanks for this, Sebastian. I'm not really working on devtools docs any more, but Janet is, so I will attempt to transfer this to her :).

Flags: needinfo?(wbamberg) → needinfo?(jswisher)

LGTM, minor edits. Thanks, Sebastian!

Flags: needinfo?(jswisher)

Thank you both for your help! So let's call this dev-doc-complete, then. :-)

Sebastian

Keywords: dev-doc-needed → dev-doc-complete
Depends on: 1635970
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: